Make the data views writable#536
Draft
jholveck wants to merge 3 commits into
Draft
Conversation
Previously (while working on 11.0), we changed the .bgra and .rgb attributes to be read-only memoryviews. We also removed the .raw attribute. The main reason we made the memoryviews read-only is so that we don't have to worry about cached values of .pixels and .rgb being in-sync with the underlying buffer, if users mutated the pixel data. However, I now realize that this takes away a possible valuable use case: ctypes. ctypes can only create an array (or pointer) from a buffer if it's writable; it doesn't support a read-only version. Previously, users could make a ctypes pointer using the .raw attribute. The new API doesn't give them that ability, without copying the data (or using ctypes' from_address, which is perilous). Read-only buffers also trigger a warning from PyTorch, although it's clearly-written and only is printed once. This PR, as it stands, makes the `.bgra` and `.rgb` properties return writable memoryviews. (It also restores `.raw`, this time as a deprecated alias of bgra, since there's no pressing need to remove the name entirely.) It also documents that, while these memoryviews are writable, actually modifying the data may cause undefined behavior. There's alternatives, of course. Instead of what I've got here, ChatGPT instead suggests that we leave .bgra and .rgb read-only (as they were in 10.2, since they were `bytes` objects), and to add a property like `.writable_bgra` or something. Its argument is as follows: > The problem with making .bgra writable and saying “mutating is UB > [undefined behavior]” is that Python users will absolutely see > writable buffer and think “cool, in-place image editing.” That’s > not UB in the fun C sense; it’s more like “congratulations, you have > a weird cache-invalidation footgun.” The API shape would be lying a > little. I'm making this PR for discussion and consensus on the best way to go.
In the release notes, one change was accidentally in PR BoboTiG#535 instead, and one change was omitted entirely. Fix.
Contributor
Author
|
@BoboTiG , @halldorfannar , do you have any comments on this, or should we just go ahead and merge it? |
4 tasks
Owner
|
I think I prefer what you've done so far. I'm not really for the ChatGPT idea. Documentation is clear enough, and I could live with UB :) If @halldorfannar has no concern, OK to merge for me. |
halldorfannar
left a comment
halldorfannar
left a comment
Contributor
There was a problem hiding this comment.
I'm also fine with this approach but found two documentation issues that I suggested fixes for.
| The {py:attr}`mss.ScreenShot.bgra` and {py:attr}`mss.ScreenShot.rgb` properties now will return bytes-like | ||
| {py:type}`memoryview` objects, not necessarily {py:type}`bytes` or {py:type}`bytearray` objects. For practical use | ||
| cases, this should not be noticible. This change was allows faster access to screenshot data, with fewer memory copies. | ||
| cases, this should not be noticible. This change was allows faster access to screenshot data, with fewer memory |
Contributor
There was a problem hiding this comment.
Suggested change
| cases, this should not be noticible. This change was allows faster access to screenshot data, with fewer memory | |
| cases, this should not be noticible. This change allows faster access to screenshot data, with fewer memory |
| @@ -139,22 +162,33 @@ def rgb(self) -> memoryview: | |||
| RGBRGB... sequence. A specific pixel can be accessed as | |||
| ``rgb[(y * width + x) * 4:(y * width + x) * 4 + 4].`` | |||
Contributor
There was a problem hiding this comment.
Suggested change
| ``rgb[(y * width + x) * 4:(y * width + x) * 4 + 4].`` | |
| ``rgb[(y * width + x) * 3:(y * width + x) * 3 + 3].`` |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously (while working on 11.0), we changed the .bgra and .rgb attributes to be read-only memoryviews. We also removed the .raw attribute.
The main reason we made the memoryviews read-only is so that we don't have to worry about cached values of .pixels and .rgb being in-sync with the underlying buffer, if users mutated the pixel data.
However, I now realize that this takes away a possible valuable use case: ctypes. ctypes can only create an array (or pointer) from a buffer if it's writable; it doesn't support a read-only version. Previously, users could make a ctypes pointer using the .raw attribute. The new API doesn't give them that ability, without copying the data (or using ctypes' from_address, which is perilous).
Read-only buffers also trigger a warning from PyTorch, although it's clearly-written and only is printed once.
This PR, as it stands, makes the
.bgraand.rgbproperties return writable memoryviews. (It also restores.raw, this time as a deprecated alias of bgra, since there's no pressing need to remove the name entirely.)It also documents that, while these memoryviews are writable, actually modifying the data may cause undefined behavior.
There's alternatives, of course. Instead of what I've got here, ChatGPT instead suggests that we leave .bgra and .rgb read-only (as they were in 10.2, since they were
bytesobjects), and to add a property like.writable_bgraor something. Its argument is as follows:I'm making this PR for discussion and consensus on the best way to go.
Changes proposed in this PR
./check.shpassed